<html>
<head>
<link rel="shortcut icon" href="./favicon.ico">
<link rel="stylesheet" type="text/css" href="./style.css">
<link rel="canonical" href="./Register_areset.html">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content="It may seem silly to implement a register module rather than let the HDL infer it, but doing so separates data and control at the most basic level, including various kinds of resets, which are part of control. This separation of data and control allows us to simplify the control logic and reduce the need for some routing resources.">
<title>Register areset</title>
</head>
<body>

<p class="inline bordered"><b><a href="./Register_areset.v">Source</a></b></p>
<p class="inline bordered"><b><a href="./legal.html">License</a></b></p>
<p class="inline bordered"><b><a href="./index.html">Index</a></b></p>

<h1>A Synchronous Register to Store and Control Data (<em>with asynchronous reset</em>)</h1>
<p>It may seem silly to implement a register module rather than let the HDL
 infer it, but doing so separates data and control at the most basic level,
 including various kinds of resets, which are part of control. This
 separation of data and control allows us to simplify the control logic and
 reduce the need for some routing resources.</p>
<h2>Power-on-Reset</h2>
<p>On FPGAs, the initial state of registers is set in the configuration
 bitstream and applied by special power-on reset circuitry. The initial
 state of a design is available "for free" <em>and can be returned to at
 run-time</em>, which removes the need for that control and data logic.</p>
<h2>Asynchronous Reset</h2>
<p>On FPGAs, the hardware reset of a flip-flop is usually asynchronous and so
 takes effect immediately rather than at the next clock edge, which can
 cause subtle bugs: a register appears to fail to capture data in
 behavioural simulation, or changes in impossible ways (within less than
 a clock cycle) in timing-annotated post-synthesis simulation. </p>
<p>The asynchronous reset is necessary to force a register reset where the
 control logic to/from the register(s) might be stuck. It is necessary to
 feed the reset from a clock-sychronous source so registers don't flip value
 close to the metastability window of a downstream register.</p>
<p><strong>If at all possible, avoid the use of the asynchronous reset</strong> and instead
 depend on the power-on-reset to initially load the reset value. This
 reduces the size of the reset network and simplifies place-and-route. Also,
 even if tied to zero, the mere <em>presence</em> of an asynchronous reset inhibits
 register retiming from happening, which is a crucial optimization to get
 faster designs with less manual work. Use the plain
 <a href="./Register.html">Register</a> instead, which has no asynchronous reset.</p>
<h2>Synchronous Reset (a.k.a. Clear)</h2>
<p>If you need to clear the register during normal operation, use the
 synchronous clear input. This may create extra logic, but that logic gets
 folded into other logic feeding data to the register, and would have been
 necessary anyway but present as another case in the surrounding logic.
 Having a clear input allows us to get to the initial power-on-reset state
 without complicating the design.</p>
<h2>Implementation</h2>
<p>Let's begin with the usual front matter:</p>

<pre>
`default_nettype none

module <a href="./Register_areset.html">Register_areset</a>
#(
    parameter WORD_WIDTH  = 32,
    parameter RESET_VALUE = 0
)
(
    input   wire                        clock,
    input   wire                        clock_enable,
    input   wire                        areset,
    input   wire                        clear,
    input   wire    [WORD_WIDTH-1:0]    data_in,
    output  reg     [WORD_WIDTH-1:0]    data_out
);

    initial begin
        data_out = RESET_VALUE;
    end
</pre>

<p>Normally, I would use the "last assignment wins" idiom (See
 <a href="./verilog.html#resets">Resets</a>) to implement the asynchronous reset,
 placing it right after the clock_enable and clear if-statments below, but
 that doesn't work here: having multiple if-statements when the reset is
 asynchronously specified in the sensitivity list (as done here) leaves no
 way to determine which event in the sensitivity list each if-statement
 should respond to.</p>
<p>Thus, correct hardware inference depends on explicitly and structurally
 expressing the priority of the asynchronous reset over the clock_enable and
 clear with nested if-statements, rather than implicitly through the Verilog
 event queue via the "last assignment wins" idiom (which we use thereafter). </p>
<p>This is very likely the <em>only</em> place you will ever need an asynchronous
 signal in a sensitivity list, or have to express explicit structural
 priority. The "last assignment wins" idiom is also one of the very few
 places where you must use an if-statement instead of a ternary operator.</p>

<pre>
    always @(posedge clock, posedge areset) begin
        if (areset == 1'b1) begin
            data_out <= RESET_VALUE;
        end
        else begin
            if (clock_enable == 1'b1) begin
                data_out <= data_in;
            end

            if (clear == 1'b1) begin
                data_out <= RESET_VALUE;
            end
        end
    end

endmodule
</pre>

<hr>
<p><a href="./index.html">Back to FPGA Design Elements</a>
<center><a href="https://fpgacpu.ca/">fpgacpu.ca</a></center>
</body>
</html>

